METHOD AND APPARATUS FOR ORDERED PREDICATE 
PHI IN STATIC SINGLE ASSIGNMENT FORM 



5 BACKGROUND OF THE INVENTION 

TECHNICAL FIELD 

The invention relates to computer program transformation techniques. More 
10 particularly, the invention relates to a <I> function which may be used when 
constructing static single assignment forms in the presence of predication. 

DESCRIPTION OF THE PRIOR ART 

1 5 Computer program transformation techniques include algorithms that are used to 
transform a sequence of instructions, such that the result of their execution is 
unchanged. The purpose of a series of transformations is to produce an 
optimized program which is either shorter in number of instructions or execution 
time, or that enables further transformations which may themselves produce a 

20 shorter execution time. 

Many recently developed program transformation techniques are based on a 
program representation called static single assignment (SSA) form. An SSA 
form is a program representation which obeys the property that each variable (or 

25 resource) name is defined statically exactly once. A resource is a program 
variable. It may be a register resource such as a general purpose register, or it 
may be a memory location. Thus, there is a single definition which may, during 
program execution, be executed multiple times. For example, the single 
definition a=x may be executed multiple times during a program run, with different 

30 values for x during each execution. 

A definition of a resource is considered to be a reaching definition at a point "P" in 
a program if there is a path from the definition to "P" along which the resource has 
not been redefined. At program locations where there are multiple reaching 
35 definitions of a variable, a special O function is inserted. Figs. (1a) an (1b) are 
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control flow graphs showing multiple reaching definitions of a variable, according to 
the prior art. 

In Fig. la, a path through edge 10 on which the block 12 contains a=x joins with a 
5 path through edge 14 on which the block 16 contains a=y at join point 18. Thus, 
at this join point, either values "x" or "y" could be obtained for "a." Fig. lb is an 
SSA representation of the Fig. 1a control flow graph. In Fig. lb, the block 12 
containing variable ai=x is on path 10, while the block 16 containing variable a2=y 
is on path 14. At the join point 1 8, the variable a3=:<l> (a1 , a2). The <E> function is a 

10 notational convenience indicating that there is some function whose value is 
dependent upon which path is taken. This O function is, therefore, a non- 
executable instruction which expresses the confluence, at a join point in a program 
control flow graph, of multiple reaching definitions. Such O function generates a 
^3 single definition of a new variable. 

1=^ It is necessary to exit an SSA form to generate code that is executable by a 

machine (computer). In general, when an SSA form is exited, and final code 
generation is performed, some O functions may need to be materialized (/.a 
J"" copies introduced on the incoming control paths) to preserve correctness. When 

Q20 a form is exited to perform allocation of registers, variables a^, a2, and a3 may be 
m merged to a single register, (see Fig. la). In order to correclty perform register 

ill allocation, all variables participating as operands or target of the same phi function 

must reside in the same register. 

25 Figs. 2a and 2b are control flow diagrams illustrating materialization of variables, 
according to the prior art. In this example, on a first path through edge 26, a^=x in 

block 32, and on a second path through edge 28, a2=y in block 34. At the join 

point 36, a>(ai,a2). 

30 If edge 28 is taken, a2 is clearty defined. However, if edges 30 and then 26 are 
taken, a2 has been defined, but so has a^. If all the variables are located in the 
same register, then a-j has ovenA^ritten a2 and it is no longer available. In this case, 
the only way to preserve the correctness of the assignment to z is to materialize 
the variables. 

35 
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Fig. 2b is a control flow diagram illustrating the materialization of the variables in 
Fig. 2a. After the assignment to a2, variable T is assigned value a2 in block 34. 
The value of a2 is now saved. At the point where x is assigned to a^, T has not 
been overwritten, even if variables a-,, ag, and a3 have all been assigned to the 
5 same register. At the join point, T is used to assign to z in block 36 instead of a2. 
Once this transformation has been made, it is correct to assign variables a^, a2, 
and a3 to the same register. This is called materializing the O function. 

A technique known as predicated execution is described in Rau, B. R, Yen, D. 
1 0 1/1/. L., Yen, 1/1/., and Towie, R. A. , "The Cydra 5 Departmental Super-computer, 
Design Philosophies, Decisions, and Trade-Offs." IEEE Computer, January 
1989, pp. 12-35; and Park, J. C. H., and Schlansker, M. , "On Predicated 
Execution," Hewlett-Packard Laboratories Technical Report HPL-91-58, May, 
=D 1991. A predicate is a Boolean value, such as "True" or "False." In predicated 

J^f15 execution, predicates are used to guard the execution of instructions. Under 
]fz predicated execution, each instruction has an associated predicate which, if true, 

then the instruction is actually executed and which, if false, then the instruction is 
effectively non-operational. With the introduction of predicated execution, the 
confluence of definitions is no longer confined to join points in the control flow 
j!^0 graph. 

iif Constructing an SSA form while using predication execution presents several 

ll new challenges: 

25 • The ^ functions may occur at any point, even in branch-free code sequences.* 

• When interferences are introduced between the a> target and its sources, they 
cannot be resolved simply by placing copy instructions on the incoming edges 
at the join point, 

30 

• O materialization is complicated by the fact that multiple variables related by a 
single phi may be live concurrently (though under different predicates). 

Fig. 3 is a control flow graph illustrating predicated execution according to the prior 
35 art. In the figure, a^ is assigned x in block 44, and a2 is assigned y in block 46. 



3 




Block 38 contains the compare which determines whether block 44 or 46 is 
executed. Thus, if the result of the compare is "true," block 44 is executed and if 
"false," block 46 is executed. At the join point at block 48, a3=<I>(ai,a2) 



5 When this code is transformed to predicated execution, predicates p^ and P2 are 
assigned to represent the *1rue" and "false" of the compare operation. If b and c 
are equal, p-i is true and P2 is false. If b and c are not equal p-| is false and P2 is 

true. These values of p^ and P2 are known as predicate guards. 

1 0 The branched control flow graph can now be constructed as a straight line 
sequence of codes (block 50). Therefore, if p-| is true, a2 = y and if P2 is true, 
a^=x. In this example, a3=<I>(a-|, a2). This O is not occurring at a confluence at a 
joint point in the graph, but just in a straight line stream of instructions. Therefore, 
5 a3 equals either a^ or a2, depending on the value of these predicates. If z=a2 at 

il 5 some later point in the code, the value of a2 must be retained. However, if all of 
~ the variables are assigned to the same register, the value of a2 cannot be 

' retained by materialization. 

During code transformations, such interferences may be introduced between the 
1 20 O target and its sources. These interferences cannot be resolved simply by 
placing copy instructions on the incoming edges at the join point such as the 
example of setting t=a2 40 in Fig. 2b. This is because the copy instructions 

would effectively be on all paths. 

25 A variable is live when it has been defined and its last use has not yet been 
reached. Because the variable's value is defined and is to be consumed at a later 
point in the instruction stream, its value must be preserved. In Fig. 3, there are 
multiple variables related by a single O and which are live concurrently. After 
predicated execution has been performed, the line of code z=a2 is moved below 

30 the point of the assignment to a3 at instruction 52. 

The variable a3 is live at instruction 52 because, presumably, at some point the 
value of a3 is to be consumed. However, when p-j is "true," the variable a2 is 
assigned the value y. Therefore, a2 is also live and both of these live values 
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interfere because multiple live participants in a O cannot be assigned to the same 
register or variable location. 

The original SSA formulation, described in Cytron, R, Ferrante, J., Rosen, B., 
5 Wegman, M., and Zadeck, K. , "Efficiently Computing Static Single Assignment 

Form and Control Dependence Graph," ACM Transactions on Programming 
Languages and Systems, 13(4):452490, October, 1991; and Choi, J., Cytron, 
R., Ferrante, J., "System and Method for Solving Monotone Information 
Propagation Problems," U.S. Patent No. 5,327,561 (July 1994), awarded to 
10 International Business Machines Corporation of Armonk, NY, did not address 
problems arising from the use of predicated execution. 

A gated form of SSA, Gated Single Assignment (GSA) was proposed in 
O Ballance, R., Maccabe, A., and Ottenstein, , "The program dependence web: 

5 a representation supporting control-, data-, and demand - driven interpretation of 

imperative languages," Proceedings of the SIGPLAN '90 Conference on 
:C Programming Language Design and Implementation, pp. 257-271, June 1990. 

l2 The GSA approach is directed to interpreting, rather than translating a program 

from the source language to a machine language. Interpreting refers to performing 
i~20 the translation on the fly as the program is executed. An interpreter looks at a 

statement in a source language and directly executes it. An interpreter is 
L^: essentially a phase of a virtual machine that implements the language in which the 

n source programmer code is written. This is significantly different from translating a 

program from source language to machine language, and then executing the 
25 program. 

In GSA, control dependence information is associated with each reaching 
definition at a O function (termed g functions in this formulation). One difference 
between GSA and SSA is the introduction of gates, which are conditions that 
30 guard the operands to a A guard indicates when the operand would be 
selected. 

However, this formulation again relies upon the association of the O node with the 
join point in the control flow graph, and expresses the full control dependence of 
35 each incoming edge at the join point, to wit, the entire chain of control decisions 
that would have had to be made for that path to have been selected. Thus, 
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GSA does not address the problems of O materialization or predicated code. 
Finally, the Ballance, et al. formulation is limited to the evaluation of a single 
condition to select between only two possible values, and therefore does not 
handle the confluence of more than two paths. 

5 

It would therefore be an advantage to provide a method and apparatus that 
permits SSA-based transformation techniques to be applied to predicated code. 
It would be a further advantage if such method and apparatus permitted the use 
of more than two operands for a key function and addressed the problem of 
1 0 materialization and did not require a O function to be at a join point in a control flow 
graph. 

SUMMARY OF THE INVENTION 

01 5 The invention relates to a method and apparatus for a <S> function which provides a 
^ mechanism for single static assignment in the presence of predicated code in a 

P computer program. Predicate guards are placed on each source operand to 

indicate the condition under which the corresponding source operand is live and to 
=i= provide correct materialization of the <1> functions after code reordering. 

h A prior art <E> function, referred to as a control function (OJ, represents a confluence 

{] of live reaching definitions at a join point in the control flow graph. For a O^, guards 

3 provided on the source operands indicate the basic block which is the source of 

the edge associated with the source operand. 

25 

The invention pairs the operands with the source basic block of the incoming 

edge(s) along which they are live. In addition, in the invention, the operands are 
ordered according to a topological ordering of their associated block. This 
ordering is maintained in a valid topological ordering through any subsequent 
30 code transformations. In the topological ordering, the source of the edge from 
which the definition was passed is defined. 

A predicate O function, Op, according to the invention, provides a mechanism for 
SSA in the presence of predicated code and permits correct materialization of the 
35 <I> functions after code reordering. For Op, the guards on the source operands 
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indicate the predicate under which the corresponding operand is defined. The <I>p 
represents the confluence of definitions in a straight line of code in which some of 
the definitions have been predicated- 

5 The order of the operands, and their associated guards, allows for the case where 
the operands are not defined under disjoint predicates. The order is such that the 
Op function can be fully materialized by inserting a copy from each source 

operand to the target variable, in the corresponding order, and each predicated 
by the associated predicate guard. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figs, la and 1 b are control flow graphs showing multiple reaching definitions of a 
3 variable according to the prior art; 

35 

2 Figs. 2a and 2b are control flow diagrams illustrating materialization of variables 

p according to the prior art; 

5^ Fig. 3 is a control flow graph illustrating predicated execution according to the prior 

^0 art; 

y Fig. 4a is a control flow graph showing a first topological ordering according to the 

Z invention; 

25 Fig. 4b is a control flow graph showing a second topological ordering according to 
the invention; 

Fig. 4c is a control flow graph showing a third topological ordering according to the 
invention; 

30 

Fig. 5a is a first example of source code according to the invention; 

Fig. 5b is a control flow graph of the first example of source code according to the 
invention; 

35 

Fig. 5c is a representation of the predicated code from the first example of source 
code according to the invention; 
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Fig. 6 shows a control flow graph and function according to the invention; 

Fig. 7 shows a resulting control flow graph and functions after transformation 
according to the invention; and 

Fig. 8 shows a resulting control flow graph and functions with an additional edge 
whose source block is not predicated according to the invention. 

DETAILED DESCRIPTION OF THE INVENTiON 

The invention is a special form of the 3> function which provides a mechanism for 
static single assignment in the presence of predicated code and introduces 
predicate guards on each source operand of a O function in a computer program. 
Such predicate guards indicate the condition under which the corresponding 
source operand is live and provide correct materialization of the O functions after 

code reordering. Previous SSA formulations have not addressed the problems 
introduced by predication. Without this mechanism, it would be necessary to 
restrict code reordering significantly to preserve correctness. 

For control O functions O the guards on the source operands indicate the basic 

block which is the source of the edge associated with the source operand. For the 
purposes of this application, a control function is the O function known under the 
prior art, enhanced with the basic block guards. A control function represents a 
confluence of live reaching definitions at a join point in the control flow graph. 

For unpredicated computer program code, the construction of functions is done 

in a manner similar to the SSA formulation proposed by Cytron et ai However, 
the invention pairs the operands with the source basic block of the incoming 
edge(s) along which they are live. In addition, in the invention, the operands are 
ordered according to a topological ordering of their associated block. This 
ordering must subsequently be maintained in a valid topological ordering through 
any subsequent code transformations. 
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Fig. 4a is a control flow graph showing a first topological ordering according to the 
invention. In the figure, the first block B1 (designated as block 54), and the 
second block B2 (designated as block 56) reach a confluence at block 58. At 
block 58, a3= <I>c( B-j-a^, B2:a2) (See block 60). This indicates that a-| is the 
5 source operand that comes fronn B1 and a2 is the source operand that connes 
from B2. In the prior art, the <t> function uses only a^ and a2, and not the 
representations B1 and B2. 

A block represented at the join point by the does not have to be the block in 

10 which a source operand is defined. Fig. 4b is a control flow graph showing a 
second topological ordering according to the invention. In Fig. 4b, a2 is defined at 

an earlier block BO 62. This block is a common predecessor of both B1 and B2. 
However, the the same as that of Fig. 4a because B2 is still the block from 

which the definition was passed to the block 58 at the join point. Thus, only the 
iU5 source of the edge from which the definition was passed must be defined. 

Because B1 and B2 are topologically at the same level, the argument of may 

J- remain the same as that of Fig. 4a. 

Fig. 4c is a control flow graph showing a third topological ordering according to the 
1^0 invention. In Fig. 4c, B2 is the source of the operand definition and is also a 
iij predecessor of B1 . Because B2 is topologically before B1 , it is listed first in the 

argument of a3 64. 

The compiler determines the topology of the blocks of code at the time that the 
25 control flow graph is built. The compiler takes a stream of code, identifies where 
the blocks and edges are and performs a topological numbering of the blocks. 
Each block is assigned a number with a lower number indicating that a block is 
topologically first. Such compiler can be readily assembled by one skilled in the 
art using well-known program techniques and equipment. 
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A predicate O function ^ p, according to the invention, provides a mechanism for 

SSA in the presence of predicated code and permits correct materialization of the 
O functions after code reordering. For a>p, the guards on the source operands 

indicate the predicate under which the corresponding operand is defined. The Op 



9 




represents the confluence of definitions in a straight line of code, where some of 
the definitions have been predicated. 

The order of the operands, and their associated guards, allows for the case where 
5 the operands are not defined under disjoint predicates. The order is such that the 
Op function can be fully materialized by inserting a copy from each source 
operand to the target variable, in the corresponding order, and each predicated 
by the associated predicate guard. 

1 0 Fig. 5a is a first example of source code. In the example, if condition c1 is true, 
then a is assigned the value x; othenwise, a is assigned the value y. 

Fig. 5b is a control flow graph of the first example of source code, according to the 
invention. The value of a1 is assigned in block B1 (designated as block 72) and 

SI 5 the value of a2 is assigned in block B2 (desingated as block 74). Block BO 
(designated as block 76), topologically above B1 and B2, is a compare 

E operation. The control function represented in block 78 is a3=<l>c(B1 :a-,,B2:a2). 

^ Fig. 5c is a representation of the predicated code from the first example of source 

.-20 code according to the invention. Instead of having the block designation on each 

d operand, the predicated code has a predicate designation on each operand. A 

H compare 80 is used to change the into predicated code. If p1 , then a-| gets y 

□ (designated as statement 82), if p2 then a2 gets x (designated as statement 84) 
and a3=Op(p1 :ai,p2:a2) (designated as statement 86). This transfers the into 

25 a Op. Thus, for example, the B1 path is now the PI path. 

As another example, consider the following source code: 

a = 1; (1) 
30 if (condition) 
a=x 

Once predicated, the Boolean result of the compare is written to a predicate, *p1 
35 used to qualify the code which is to be executed when that condition is TRUE. 
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The above code is transformed to the following: 



a = 1; 



(2) 



p1 = (condition); 
p1 ? a = x; 

At the end of this sequence, the variable 'a' has two reaching definitions. In SSA 
form, a O function is required to express the confluence of these definitions: 



pi = (condition); 
pi ? a, = x; 

^2 =^p(TRUE:ao, p1:a|); 

The code may be re-ordered as follows, for example, if the assignment of a^ 
involved a long-latency load of x: 

ai = x; (4) 

ao = 1 ; 

p1 = (condition); 

aa = <I>p(TRUE:ao, pi :a|); 

To transform this code out of SSA fonn correctly, the <Dp function is materialized 
by inserting copies in the order of its operands: 



ao = 1; 

pi = (condition); 
a2 = ao; 
p1?a2 = a,; 

Finally, unnecessary copies are eliminated, producing the following: 



ao= 1; 



(3) 



=x; 



(5) 



ai =x; 



(6) 
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82=1; 

p1 = (condition); 
pi ? a2 = a^; 

5 The construction of Op functions is performed in two places. First, during the initial 

construction of SSA form, predicate <I>p functions are inserted after all existing 

predicated definitions. The pseudo code which accomplishes this is an extension 
of the algorithm proposed by Cytron et al, and is included in Table 1 . 

10 TABLE 1. Pseudo code for constructing predicate O functions 

search(currentBasicBlock) 
{ 

W for each Instruction, thislnst in currentBasicBlock do 

^3 5 if thislnst is a non-a>-instruction then do 

H rename uses 

JC for each resource V defined in thislnst do 

f ^ U = clone(V) 

Replace V with U as the target being defined 
=20 if thislnst is predicated by P != TRUE then do 

Y = topOfStack{V) 
jy W = clone(V) 

O newlnst = "W = a>p(TRUE:Y,P:U)" 

insert newlnst after thislnst 
25 push W onto Stack(V) 

else 

push U onto Stack(V) 
endif 
endfor 
30 endfor 

As is shown by the pseudo code of Table 1 , the compiler searches the current 
block and goes through each instruction in the source code instructions. For a non- 
O instruction, all of its uses are renamed. Every resource that is actually defined 
35 by this instruction needs a new name because there can only be one definition in 
each variable. Therefore, the variable "V" is cloned to produce a "U." 
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A cloned resource is a resource resulting from a renaming of another resource. It 
duplicates all of the properties of the original resource, such as resource type. 
Thus, if "V" is a general purpose register, "U" is also a general purpose register. 
5 If "V" is a stack location then "U" is a new stack location. "V" is then replaced by 
"U" in that instruction. 

If this instruction is predicated by a predicate P which is not a "CONSTANT 
TRUE," it is in predicated form. By contrast, if the predicate is true, the instruction 
1 0 is not predicated because it is always executed. 

For a predicated instruction, a new resource "Y" is created which is a clone of "V." 
"Y" is then assigned whatever clone of "V" is currently on the top of stack. "V" is 
then cloned again to produce "W." 

lis 

"W" is defined as equal to the result of the predicate O where "Y" is the value for 
V "TRUE" and "U" is the value under P for the current predicate. Thus, the incoming 

?n value is "Y", but if P is "TRUE" then the value is "U." This follows topological 

;~ ordering because "TRUE" is always a superset of P. 

'^20 

JtJ The construction of Op functions is also done when control flow is replaced by 

IJJ predication while already in SSA form. At that time, the control functions are 

n either replaced or augmented with predicate Op functions. The pseudo-code to 

^ " replace or augment the control O^ functions is shown in Table 2. The pseudo- 

25 code takes as input the control O^ function to be transformed. A mapping from 

predicated basic blocks to their associated predicate, and the set of basic blocks 
which have been predicated are also taken as input. 

Table 2. Pseudo Code For Transforming O^ Functions to Op 
30 Functions After Predication 

transform(Oc Inst, predicateMap, predicatedBlocks ) 
{ 

V = target(Oc Inst) 
35 Set S = set of source basic blocks for O^ Inst 
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// Identify any blocks which were not transformed 
Set T = ( S - predicatedBlocks ) 
if T== S then return 
Oplnst = "V = a>p()" 

if size(T) > 1 then 

// need to retain control phi 
W = clone (V) 
target (O^lnst) = W 

add operand {W, TRUE} to Opinst ( as first operand) 

else if size(T) = = 1 then 
B = single block in T 

U = source operand associated with B in Oc Inst 
add operand {U, TRUE} to Opinst (as first operand) 
delete operand {U,B} from Inst 
endif 

for each [source operand R, basic block B} of Inst 
do 

if B in predicatedBlocks then do 

delete operand {R,B} from Inst 

add operand {R,predicateMap[B]} to OpInst (operands are added in 

order) 

endif 
endfor 

if O^lnst has no operands, then delete it 

In the Table, some blocks are eliminated and completely replaced by predicated 
instructions in another block. The first argument is the instruction that may or 

may not be transformed. The predicate map is a mapping from a block to its 
associated predicate. Predicated blocks are a set of blocks that have been 
completely predicated. 

The source basic blocks "S," which are all the blocks whose edges contribute to 
the O instruction, are identified, and the difference between "S" and the predicated 
blocks is placed into "T." Therefore, "T" is now the set of all blocks which have 
associated operands in the 4>c, and which have not been eliminated by 
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predication. If 'T' and "S" are the same, then all of the blocks involved in the 
still exist and have not been predicated, in such case, there is a return and nothing 
is done by the program. 

5 If "T" and "S" are different, a instruction with no operand is generated. If the 
size of "T" is greater than 1 , the is retained. This is because there still exists a 
control flow join of multiple blocks. The target of the existing <I>c instruction is set to 
"W," and the operand "W, TRUE" is added to the Op instruction. 

1 0 If the size of T is equal to 1 , then "B" is the single block in that set and "U" is the 
source operand associated with "B" in the original instruction. In such case, "U" 

is added as a "TRUE" operand to the Op and is deleted from the O^. Because 

"B" is now, being reflected as the first operand of the O^, the O^ can be 

]^ eliminated. This is because the only resource entering the newly merged block is 

|2l5 now"U." 

12 All of the operand pairs in the original O^ instructions are now processed. For 

each operand pair (R, B), if the block is in the predicated blocks, then that pair is 
n deleted from the O^ and another operand pair is added to the Op instruction. This 

•?;20 new operand pair is "R," paired with the predicate for B from the predicate map. 
lU If the Oc has no operand after processing all of its operand pairs, it is deleted. 

The topological ordering of the block's O^ is significant in the last loop of the 
pseudo code. This loop goes through a traversal of the operands of the O^'s and 
25 adds the operands in that same order to the Op's. If the O^'s operands were in 
topological order, then the Op's are in an order such that they can be materialized 
to give correct results. 

Figs. 6 and 7 show the same control flow graph and O^ function, and the resulting 
30 graph and functions after transformation. In Fig 6., block BO (designated as 90) 
contains a compare such that if true the path to the block B2 (designated as 92) is 
followed and if false the path to block B1 (designated as 94) is followed. p2 gets 
the result of this compare 96. The definition of x^ is under p1 and the definition X2 
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is under p2. Because B1 and 82 are topologically equal, their order in the <I>c is 
not important. 

In Fig. 7, the assumption is made that 81 is rarely executed and the "TRUE" path 
is generally followed. Thus, it is not important to predicate the value in block 

81 because it is not expected to be executed. It is therefore left as a branch. 

The example in Fig. 8 is similar to that of Fig. 7, but there is an additional edge 
(and associated incoming value of x) whose source block is not predicated. In 
Fig. 8, blocks 81 and 80 have been predicated while block 84 is unaffected by 
predication. This requires both types of phi at the merge - a to reflect the 

presence of control join edge and a Op to reflect the predication. 

Although the invention is described herein with reference to the preferred 
embodiment, one skilled in the art will readily appreciate that other applications 
may be substituted for those set forth herein without departing from the spirit and 
scope of the present invention. It is readily apparent that one skilled in the art can 
provide the source code required to construct the predicate phi instructions of the 
invention using well-known programming techniques and equipment. 

The invention is applicable to any compiler-based computer programming 
languages for use on different types of computers, including network servers, and 
desktop computers. 

Accordingly, the invention should only be limited by the Claims included below. 
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